TODO

• Add patterns for multiple backends
• Add more real examples
• Review and come up with pattern for stdio dependency modelling
• Say something about select is now preferred, opposed to linux and zephyr, so that applications will not require different configs for each hardware configuration
• circular dependencies

It seems pretty unpleasant to link separate kconfig files from the docs... My current solution will be adding a commit after everything is rebased and squashed to point to the commit hashes of the linked kconfig files. This must happen at the end though.

oops

Note, if there are no configurable options for a driver level module then it can be config not menuconfig as to not confuse a kconfig user into thinking there may be more options available.

TODO:

Add something about board specific configs and overriding configs. Adding hardcoded modules to a $(BOARD).config and modules that require dependencies to the board Kconfig with an overriding config (or choice), keeping in mind that the depends on * must be duplicated for the config only.

Now that all the boards are in, it would be good to settle on this.

Before the big push in the networking I would like this, and an update based on this (possibly some treewide updates).

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

What's the current state of this documentation? Is this ready to be reviewed? I cloud do a try to understand what you're describing and point out what's unclear to me review.

Hmmm, I have something of a chicken and egg problem with the current state, I want the links to work but they won't until it is in.

Let me have another go at it (once I am done trying to fix the nightlies). I will ping you sometime next week when I will be ready... That is unfortunately the speed that I work.

Oh don't worry - I really don't want to put any pressure onto you. Take the time you need.

I'm just keen to get Kconfig in - doing all the dependency modeling twice for every bit you add or change is good advertisement to move to only one dependency system ... and I'd say Kconfig is the better choice here.